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POST OFFICE PROTOCOL — VERSION 2 


Status of this Memo 


This RFC suggests a simple method for workstations to dynamically 
access mail from a mailbox server. This RFC specifies a proposed 
protocol for the ARPA-Internet community, and requests discussion and 
suggestions for improvement. This memo is a revision of RFC 918. 
Distribution of this memo is unlimited. 


Introduction 


The intent of the Post Office Protocol Version 2 (POP2) is to allow a 
user's workstation to access mail from a mailbox server. It is 
expected that mail will be posted from the workstation to the mailbox 
server via the Simple Mail Transfer Protocol (SMTP). For further 
information see RFC-821 [1] and RFC-822 [2]. 


This protocol assumes a reliable data stream such as provided by TCP 
or any similar protocol. When TCP is used, the POP2 server listens 
on port 109 [4]. 


System Model and Philosophy 


While we view the workstation as an Internet host in the sense that 
it implements IP, we do not expect the workstation to contain the 
user's mailbox. We expect the mailbox to be on a server machine. 


We believe it is important for the mailbox to be on an "always up" 
machine and that a workstation may be frequently powered down, or 
otherwise unavailable as an SMTP server. 


POP2 is designed for an environment of workstations and servers on a 
low-delay, high-throughput, local networks (such as Ethernets).  POP2 
may be useful in other environments as well, but if the environment 
is substantially different, a different division of labor between the 
client and server may be appropriate, and a different protocol 
required. 


Suppose the user's real name is John Smith, the user's machine is 
called FIDO, and that the mailbox server is called DOG-HOUSE. Then 
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we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA 
(not JSmith@FIDO.ARPA). 


That is, the destination of the mail is the mailbox on the server 
machine. The POP2 protocol and the workstation are merely a 
mechanism for viewing the messages in the mailbox. 


The user is not tied to any particular workstation for accessing his 
mail. The workstation does not appear as any part of the mailbox 
address. 


This is a very simple protocol. This is not a user interface. We 
expect that there is a program in the workstation that is friendly to 
the user. This protocol is not "user friendly". One basic rule of 
this protocol is "if anything goes wrong close the connection". 
Another basic rule is to have few options. 


POP2 does not parse messages in any way. It does not analyze message 
headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply transmits 
whole messages from a mailbox server to a client workstation. 


The Protocol 


The POP2 protocol is a sequence of commands and replies. The design 
draws from many previous protocols of the ARPA-Internet community. 


The server must be listening for a connection. When a connection 
is opened the server sends a greeting message and waits for 
commands. When commands are received the server acts on them and 
responds with replies. 


The client opens a connection, waits for the greeting, then sends 
the HELO command with the user name and password arguments to 
establish authorization to access mailboxes. The server returns 
the number of messages in the default mailbox. 


The client may read the default mailbox associated with the user 
name or may select another mailbox by using the FOLD command. The 
server returns the number of messages in the mailbox selected. 


The client begins a message reading transaction with a READ 
command. The read command may optionally indicate which message 
number to read, the default is the current message (incremented 
when a message is read and set to one when a new folder is 
selected). The server returns the number of characters in the 
message. 
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The client asks for the content of the message to Dbe sent with the 
RETR command. The server sends the message data. 


When all the data has been received the client sends an 
acknowledgment command. This is one of ACKS, ACKD, and NACK. 


ACKS means "I've received the message successfully and please 
keep it in the mailbox". 


ACKD means "I've received the message successfully and please 
delete it from the mailbox". 


NACK means "I did not receive the message and please keep it in 
the mailbox". 


In the case of ACKS or ACKD the server increments the current 
message indicator. In the case of NACK the current message 
indicator stays the same. 


In all cases the server returns the number of characters in the 
(now) current message. 


The client terminates the session with the QUIT command. The 
server returns an ok. 
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The Normal Scenario 


Wait for Connection 
Open Connection --> 
«-- + POP2 Server Ready 
Wait for Command 
HELO Fred Secret --> 


«-- #13 messages for you 
Wait for Command 
READ 13 --> 
«-- =537 characters in that message 
Wait for Command 
RETR ==> 
<-- (send the message data) 
Wait for Command 
ACKS --» 
<-- =0 no more messages 
Wait for Command 
QUIT --» 
<-- + OK 
Close connection --> «-- Close connection 
Wait for Connection (go back to start) 
Conventions 
Arguments 


These arguments have system specific definitions. 
user - A login account name. 
password - The password for the login account. 


mailbox — A mailbox name (also called a mail folder). 
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Default Mailboxes 
TOPS-20 
MAIL.TXT.1 - from login directory 
UNIX 


both 
/usr/spool/mail/user 
and 
/usr/user/Mail/inbox/* 


where "user" is the user value supplied in the HELO command. 


End of Line 


End of Line is Carriage Return (CR) followed by Line Feed (LF). 
This sequence is indicated by "CRLF" in this document. This end 
of line convention must be used for commands and replies. 


Message Length 


The reply to the READ command or an acknowledgment command (ACKS, 
ACKD, NACK) is the length (a character count) of the next message 
to be transmitted. This includes all the characters in the data 
transmitted.  CRLF counts as two characters. A length of zero 
means the message does not exist or is empty. A request to 
transmit a message of zero length will result in the server 
closing the connection. The message is transmitted in the 
standard internet format described in RFC-822 [2] and NVT-ASCII. 
This may be different from the storage format and may make 
computing the message length from the stored message non-trivial. 


Message Numbers 


The reply to the HELO and FOLD commands is a count of the number 
of messages in a the selected mailbox. The READ command has a 
message number as an optional argument. These numbers are 
decimal, start at one, and computed with respect to the current 
mailbox. That is, the first message in a mailbox is message 
number 1. 


Numbers 


All numbers in this memo and protocol are decimal. 
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Quoting 


In a few cases, there may be a need to have a special character in 
an argument (user, password, or mailbox) that is not allowed by 
the syntax. For example, a space in a password. To allow for 
this, a quoting convention is defined. Unfortunately, such 
quoting conventions "use up" another otherwise uninteresting 
character. In this protocol the back slash "N" is used as the 
quote character. To include a space in an argument the two 
character sequence "back-slash, space" is transmitted. To include 
a back-slash in an argument the two character sequence 
"back-slash, back-slash" is transmitted. This quoting convention 
is used in the command arguments only, it is not used in the mail 
data transmitted in response to a RETR command. 


Reply Strings 
The first character is required to be as specified (i.e., 


"+N, "=", "=", K"#"). The optional strings that follow can be 
whatever the implementer thinks is appropriate. 


Definitions of Commands and Replies 


Summary of Commands and Replies 


Commands Replies 
HELO user password + OK 
FOLD mailbox - Error 
READ [n] #xxx 
RETR =yyy 
ACKS 

ACKD 

NACK 

QUIT 
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Commands 
HELO user password 


The Hello command identifies the user to the server and carries 
the password authenticating this user. This information is 
used by the server to control access to the mailboxes. The 
Hello command is the "HELO" keyword, followed by the user 
argument, followed by the password argument, followed by CRLF. 


Possible responses: 
"#nnn" 


where nnn is the number of messages in the default 
mailbox, H 


"- error report" and Close the connection. 
FOLD mailbox 


The Folder command selects another mailbox or mail folder. The 
server must check that the user is permitted read access to 
this mailbox. If the mailbox is empty or does not exist, the 
number of messages reported is zero. The Folder command is the 
"FOLD" keyword, followed by the mailbox argument, followed by 
CRLF. 


Possible responses: 
" Ennn " 
where nnn is the number of messages in this mailbox. 
READ [nnn] 


The Read command begins a message reading transaction. If the 
Read command is given without an argument the current message 
is implied (the current message indicator is incremented by 
the ACKS or ACKD commands). If an argument is used with the 
Read command it is the message number to be read, and this 
command sets the current message indicator to that value. The 
server returns the count of characters in the message to be 
transmitted. If there is no message to be read, the count of 
zero is returned. If the message was previously deleted with 
the ACKD command, the count of zero is returned. The Read 
command is followed by the RETR command, the READ command, the 
FOLD command, or the QUIT command. Do not attempt to RETR a 
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message of zero characters. The Read command is the "READ" 
keyword, optionally followed by the message number argument, 
followed by CRLF. 


Possible responses: 
"=ccc" 
where ccc is the number of characters in this message. 


RETR 


The Retrieve command confirms that the client is ready to 
receive the mail data. It must be followed by an 
acknowledgment command. The server will close the connection 
if asked to transmit a message of zero characters (i.e., 
transmit a non-existent message). The message is transmitted 
according to the Internet mail format standard RFC-822 [2] in 
NVI-ASCII. The Retrieve command is the "RETR" keyword, 
followed by CRLF. 


Possible responses: 
the message data 
Close the connection 
ACKS 


The Acknowledge and Save command confirms that the client has 
received and accepted the message. The ACKS command ends the 
message reading transaction. The message is kept in the 
mailbox. The current message indicator is incremented. The 
server returns the count of characters in the now current 
message to be transmitted. If there is no message to be read 
or the message is marked deleted, the count of zero is 
returned. The Acknowledge and Save command is the "ACKS" 
keyword, followed by CRLF. 


Possible responses: 
"=ccc" 


where ccc is the number of characters in the next 
message. 
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ACKD 


The Acknowledge and Delete command confirms that the client has 
received and accepted the message. The ACKD command ends the 
message reading transaction. If the user is authorized to have 
write access to the mailbox, the message is deleted from the 
mailbox. Actually, the message is only marked for deletion. 
The actual change is made when the mailbox is released at the 
end of the session or when the client selects another mailbox 
with the FOLD command. The messages are not renumbered until 
the mailbox is released. If the user does not have write 
access to the mailbox no change is made to the mailbox. The 
response is the same whether or not the message was actually 
deleted. The current message indicator is incremented. The 
server returns the count of characters in the now current 
message to be transmitted. If there is no message to be read 
or the message is marked deleted, the count of zero is 
returned. The Acknowledge and Delete command is the "ACKD" 
keyword, followed by CRLF. 


Possible responses: 
"=ccc" 


where ccc is the number of characters in the next 
message. 


NACK 


The Negative Acknowledge command reports that the client did 
not receive the message. The NACK command ends the message 
reading transaction. The message is kept in the mailbox. The 
current message indicator remains the same. The server returns 
the count of characters in the current message. Since the 
count to be returned is for the message just transmitted it the 
message must exist and not be marked deleted, and the count 
must be positive (non-zero). The Negative Acknowledge command 
is the "NACK" keyword, followed by CRLF. 


Possible responses: 
"=ccc" 


where ccc is the number of characters in this message. 
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QUIT 


The Quit command indicates the client is done with the session. 
The server sends an OK response and then closes the connection. 
The Quit command is the "QUIT" keyword, followed by CRLF. 


Possible responses: 
"+ OK" and Close the connection 
Replies 
Greeting 


The greeting is sent by the server as soon as the connection is 
established. The greeting is a plus sign, followed by the 
protocol name ("POP2"), followed by the server host name, 
optionally followed by text, and ending with a CRLF. 


The success or plus sign response indicates successful 
completion of the operation specified in the command. The 
success response is a plus sign, optionally followed by text, 
and ending with a CRLF. 


The failure or minus sign response indicates the failure of the 
operation specified in the command. The failure response is a 
minus sign, optionally followed by text, and ending with a 
CRLF. 


The length or equal sign response tells the length in 
characters of the message referenced by the command. The 
length response is a equal sign, followed by a number, 
optionally followed by text, and ending with a CRLF. 


The count or number sign response tells the number of messages 
in a folder or mailbox referenced by the command. The count 
response is a number sign, followed by a number, optionally 
followed by text, and ending with a CRLF. 
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Timeouts 


In any protocol of this type there have to be timeouts. Neither 
side wants to get stuck waiting forever for the other side 
(particularly is the other side has gone crazy or crashed). 


The client expects a reply to a command fairly quickly and so 
should have a short timeout for this. This timeout is called Tl. 


For some servers, it may take some processing to compute the 
number of messages in a mailbox, or the length of a message, or 
to reformat a stored message for transmission, so this time out 
has to allow for such processing time. Also care must be taken 
not to timeout waiting for the completion of a RETR reply while 
a long message is in fact being transfered. 


The server expects the session to progress with some but not 
excessive delay between commands and so should have a long timeout 
waiting for the next command. This time out is T2. 


One model of use of this protocol is that any number of 
different types of clients can be built with different ways of 
interacting with the human user and the server, but still 
expecting the client to open the connection to the server, 
present a sequence of commands, and close the connection, 
without waiting for intervention by the human user. With such 
client implementations, it is reasonable for the server to have 
a fairly small value for timeout T2. 


On the other hand, one could easily have the client be very 
human user directed with the user making decisions between 
commands. This would cause arbitrary delays between client 
commands to the server, and require the value of timeout T2 to 
be quite large. 


Implementation Discussion 
Comments on a Server on TOPS-20 


On TOPS-20, a mailbox is a single file. New messages are appended 
to the file. There is a separator line between messages. 


The tricky part of implementing a POP2 server on TOPS-20 is to 
provide for deleting messages. This only has to be done for the 
mailboxes (files) for which the user has write access. The 
problem is to avoid both (1) preventing other users from accessing 
or updating the mailbox for long periods, and (2) accidentally 
deleting a message the user has not seen. 
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suggestion is as follows: 


When a mailbox is first selected, if the user has write access, 
rename the mailbox file to some temporary name. Thus new 
messages will be placed in a new instance of the mailbox file. 
Conduct all POP2 operation on the temporary mailbox file 
(including deleting messages). When the POP2 session is over 
or another mailbox is selected, prepend any messages left 
undeleted in the temporary file to the new instance of the 
mailbox file. 


maximum length of a command line is 512 characters (including 
command word and the CRLF). 


maximum length of a reply line is 512 characters (including 
success indicator (+, -, =, #) and the CRLF). 


maximum length of a text line is 1000 characters (including 
F). 


s developed a POP2 server for TOPS-20 and for Berkeley 4.2 
and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix. 


s Not Supported 


oes not examine the internal data of messages. In particular, 
rver does not parse message headers. 


rver doesn't have any state information (i.e., it doesn't know 
ne session to the next what has happened). For example, the 
doesn't know which messages were received since the last time 
er used POP2, so it can't send just the "new" messages. 
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Example 1: 


Client 


Open connection --> 


<—— 


HELO POSTEL SECRET --> 


READ --» 
RETR --» 
ACKD --» 
RETR --» 
ACKD == 
QUIT ==>. 


Close connection --> 
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Server 

Wait Ee 

+ POP2 USC-ISIF.ARPA Server 
#2 messages in your mailbox 
=537 characters in message 1 
[data of message 1] 

=234 characters in message 2 
[data of message 2] 

=0 no more messages 

+ OK, bye, bye 


Close connection 
Go back to start 
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Example 2: 


Butler, 


Close connection --> 


et. al. 


Wait for connection 

+ POP2 ISI-VAXA.ARPA server here 
#35 messages 

#27 messages 

=10123 characters in that message 
[data of message 27] 

=0 no more messages 

+ bye, Call again sometime. 


Close connection 
Go back to start 


Server 
Wait for connection 


+ POP2 ISI-VAXA.ARPA server here 


#0 messages 


Open connection  --» 

<—— 
HELO smith secret --> 

<—— 
FOLD /usr/spool/mail/smith --> 

<—— 
READ 27 --> 

<—— 
RETR --> 

<—— 
ACKS --> 

<—— 
QUIT --> 

<—— 
Close connection --» «-- 

Example 3: 
Client 

Open connection  --» 

<—— 
HELO Jones secret --> 

<—— 
READ --> 

<—— 


Close connection 


Go back to start 
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Formal Syntax 


<digit> zog EC Dar 40 E NA Wee | Bee 

«letter» = A | B | C | ... | 
a | b| c| | z 

<punct> SARA e A oy h ae] 
Fie SIE e UR es ls pe | 
Deet EA MESE pns 

<quote> =N 

<any> = any one of the 128 ASCII codes 

<CR> = carriage return, code 10 

<LF> = line feed, code 13 

<SP> = space, code 32 

<CRLF> = <CR> <LF> 

<print> = «letter» | «digit» | <punct> | «quote» «any» 

«char» = <print> | <SP> 

<word> = <print> | <print> <word> 

<string> = <char> | <char> <string> 

<1d> = <letter> | <digit> 

«ldh» - «letter» | «digit» | - 

<ldhs> = <ldh> | <ldh> <ldhs> 

<name> = <letter> [ [ <ldhs> ] <ld> ] 

<host> = <name> | <name> . <host> 

<user> = <word> 

<password> = <word> 

<mailbox> = <string> 

«number» = «digit» | «digit» «number» 
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<helo> = HELO <SP> <user> <SP> <password> <CRLF> 
<fold> = FOLD <SP> <mailbox> <CRLF> 
<read> = READ [<SP> <number>] <CRLF> 
<retr> = RETR <CRLF> 
<acks> = ACKS <CRLF> 
<ackd> = ACKD <CRLF> 
<nack> = NACK <CRLF> 
<quit> = QUIT <CRLF> 
<ok> = + [<SP> <string>] <CRLF> 
<err> = — [<SP> <string>] <CRLF> 
<count> = # <number> [<SP> <string>] <CRLF> 
<greet> = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF> 
<length> = = <number> [<SP> <string>] <CRLF> 
«command» = «helo» | «fold» | «read» | <retr> | 
«acks» | «ackd» | «nack» | «quit» 
«reply» = «ok» | «err» | «count» | «length» | «greet» 
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Client State Diagram 


| 
| Open 
| Greet 
V AS 
4------- * QUIT 
| cann |------------- 
4+------- + 
| 
| Greet 
HELO 
+---->+ | 
#NNN ^ | | #NNN 
— | V V == == 
FOLD | +------- + QUIT 
*«---| NMBR |---------------- 
4+------- + 
B | 
| | #NNN 
| || = = 
-CCC | READ 
FOLD | -CCC 
| v SON 
-CCC  4---»4------- * QUIT 
---- ^ | SIZE |---------------- 
READ +<---+------- + 
| | =CCC 
data | | ---- 
---- | | RETR 
ack | 
V 
4+------- + 
| XFER | 
4+------- + 
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| en 
| Close 
4R------- + 
>| EXIT | 
4R------- + 

| 

| 

| 

| 

| 

— >+ 

| 

| 

| 

— >+ 
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Server State Diagram 


a maa muka + Close 
| | — 
Listen | Close 
V 
4+------- + 4+------- + 
| LSTN | | DONE | 
4+------- + 4+------- + 
| A 
| Open | 
Greet | 
| | 
| QUIT | 
ç eee | 
4£------- + + BYE 
| AUTH  |--------------------- >+ 
4+------- + Š 
| | 
| HELO | 
| == 
| #NNN 
| QUIT 
Ve | 
FOLD +--->+------- + + BYE | 
---- ^ | MBOX  |--------------------- >+ 
NNN  4«---4------- + a 
| | READ 
FOLD | | — | 
===. | | =ccc | 
#NNN | QUIT 
V Pe M C 
READ  4---»4------- + + BYE 
---- ^ | ITEM |--------------------- >+ 
-CCC  t&---4------- + 
: | 
| | RETR 
ack | | — 
==== data 
=CCC 
| V 
4+------- + 
| NEXT | 
4+------- + 
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Combined Flow Diagram 
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Feet 
|CALL | <-> —— + 
| LSTN| A 
+----+ | 

| Greet 
| +----------------------------------------------------- >+ 
| ^ QUIT | 
V V 
Feet deet 4+----+ 
|CALL| HELO  |NMBR| | EXIT | 
| AUTH | ------- >| AUTH| | AUTH | | 
+————+ +————+ +—-———+ | 
| #NNN + Bye | | 
| | | 
+--------------------------------- >+ 
^ QUIT | | | 
V V 
4+--->+----+ deet +----+ | 
FOLD ^ |NMBR| READ [SIZE] |EXIT| | 
---- | | MBOX | ------- > | MBOX | [MBOX| | 
#NNN 4«---4----4 deet 4+----+ 
I | =CCC + Bye | | 
FOLD 4«-------- + | 4+------------------- >+ | | 
SE ^ | ^ QUIT | | | | 
#NNN SEI V | | | 
4+--->+----- + 4+----+ Feet 
READ ^ [SIZE | RETR |xXFER| | EXIT | | | 
---- | | ITEM|------- >| ITEM| pITEM| | | 
=CCC +<---+----- + Fet +----+ | | 
e | data | | | 
sce V * Bye | | 
Feet deet 
|SIZE| Ack |XFER| MH Ai 
| NEXT | «------- | NEXT | | | | | 
— + Rai Y 
| [| | 
| | | | 
V V V 
4------- + | 
| EXIT |-->+ 
| DONE | 
4+------- + 
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Client Decision Table 


| STATE | 
= qp—————————————————————————————————— 
INPUT | CALL | NMBR | SIZE | XFER | EXIT | 
————— Á— = +———————=s=s——— d 
Greets AA A XE db 
Se qp—————————————————————————————————— 
NNN | i1 | 3 | 1 | 3 | 6 
------- — II 
EE nb hn wey CH "me A 
RE A qp—————————————————————————————————— 
data, | ia qw bd s dp 
------- +----------------------------------| 
+ Bye | ı | ı | 1 qeu. | 6 
------- +----------------------------------| 
Close. | á | + | £ | + | 6 
Sa A. qp—————————————————————————————————— 
other | 1 | 1 | 31 | 31 | 6 
------- +----------------------------------| 
Timeout | 1 | 1 | 1 | 1 | 6 | 
— — I | 
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Actions: 


1. This is garbage. 


Send 


"QUIT", 


February 1985 


and go to EXIT state. 


2 (a) If the greeting is right then send "HELO" 
and go to NMBR state, 
(b) Else send "QUIT" and go to EXIT state. 
3s (a) If user wants this folder and NNN > 0 
then send "READ" and go to SIZE state, 
(b) If user wants a this folder and NNN - 
then send "QUIT" and go to EXIT state, 
(c) If user wants a different folder 
then send "FOLD" and go to NMBR state. 
4. (a) If user wants this message and CCC > 0 
then send "RETR" and go to XFER state, 
(b) If user wants a this message and CCC - 
then send "QUIT" and go to EXIT state, 
(c) If user wants a different message 
then send "READ" and go to SIZE state. 
Dis (a) If user wants this message kept 
then send "ACKS" and go to SIZE state, 
(b) If user wants a this message deleted 
then send "ACKD" and go to SIZE state, 
(c) If user wants a this message again 
then send "NACK" and go to SIZE state. 
6. Close the connection. 
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Server Decision Table 


| STATE 

Sens ai TE t E aod L qp————————————————————————————————————————— 
INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE 
== Ec qp————————————————————————————————————————— 
Open. ON a x oh o eh HE d. 35S pw 

= E qp————————————————————————————————————————— 
HELO | 1 | 3 | 1 ] 1 ] 1 | 1 

AA Ses qp————————————————————————————————————————— 
Keep, vrbe 1) xe, CZ, ks 0t xe. e a 

g Se qp————————————————————————————————————————— 
READ | 1 | 1 ene | 6 | 1 | 1 
------- +-----------------------------------------| 
RETR. At 27 ee "dt oe A E: A | oa 
= qp————————————————————————————————————————— 
MORS: A A oe ES Kee" 2 

SS eS en qp————————————————————————————————————————— 
BORD ue. NS s qe. "US cupeme- |. a 
C ey ass qp————————————————————————————————————————— 
NACK: (| +q spe. | ow | + Jj 1 
------- — IIIa 
OUTER ` "E, I | 24 ¿| Ir Xx Wo 

EOM eg qp————————————————————————————————————————— 
Giese” T q Mee xb un See WEE D v9 

= — M ed eg +—————————=—-— =-= r-s<=—-—=—-——— p 
ocher | a j| 11 | 131 | 131 | 1 | 1 
------- +-----------------------------------------| 
Timeout | e fe E E ie do ee 
------- — IE IAUW 
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Actions: 
1. This is garbage. Send "- error", and Close the connection. 
2. Send the greeting. Go to AUTH state. 


35 (a) If authorized user then send "#NNN" and go tp MBOX state, 
(b) Else send "- error" and Close the connection. 


4. Send "+ Bye" and go to DONE state. 
5. Send "+NNN" and go to MBOX state. 
6. Send "=CCC" and go to ITEM state. 


7. If message exists then send the data and got to NEXT state, 
Else Close the connection. 


8. Do what ACKS/ACKD/NACK require and go to ITEM state. 


9. Close the connection. 
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